REMARKS 

Claim 8 has been amended. Claims 1 - 31 are pending in the application. 
Reconsideration is respectfully requested in light of the following remarks. 

Section 112, Second Paragraph, Rejection : 

The Examiner rejected claim 8 under 35 U.S.C. §112, second paragraph, as 
indefinite. Applicants respectfully traverse this rejection for the previously stated 
reasons. In order to expedite prosecution, claim 8 has been amended. However, even 
under the amended claim language, Applicants assert that one of ordinary skill in the art 
of distributed computing would easily recognize that if a gateway was distributed over a 
plurality of servers, the implementation might not be exactly identical on each server but 
still be considered functionally identical. 

For at least the reasons above, Applicants respectfully request removal of the § 
1 12 rejection of claim 8. 

Section 102(e) Rejection : 

The Examiner rejected claims 1-5, 7-12, 14 and 17-31 under 35 U.S.C. § 102(e) 
as being anticipated by Carre (U.S. Patent 6,282,579). Applicants respectfully traverse 
this rejection for at least the reasons below. 

Regarding claim 1, Carre fails to disclose a client generating a request for 
type information for an attribute or event, contrary to the Examiner's contention. 

Carre pertains to address conversion between CORBA objects and OSI objects (Carre - 
col. 1, lines 9-19; col. 1, line 59 - col. 2, line 46) and to the transforming of object 
interfaces column 5, lines 49-59). Carre teaches a system in which CORBA interfaces 
and messages are used to communicate with and request services from managed objects. 
The Examiner cites the Abstract, FIG. 2 A, 2B, as well as column 3, lines 18-55 and 
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column 5, lines 4-38 of Carre. However, Carre does not mention anything about a client 
generating a request for type information, either at the Examiner's cited passages or 
elsewhere. In order to permit address interaction between objects that use different 
addressing modes, Carre's system converts an address type with an address value 
according to one addressing mode to a corresponding type of another specification 
language or addressing mode. (Carre, column 1, line 59 - column 2, line 6; column 2, 
lines 11-14; lines 25-28; and lines 34- 39). Thus, Carre is concerned with converting 
address types and object interfaces, but fails to teach anything regarding a client 
generating a request for type information. Converting address types and object interfaces 
does not disclose a client generating a request for type information. 

Carre teaches that client objects request services provided by service objects. 
Carre further teaches that a client object sends a request message to a service object that 
contains an operation, a target object, one or more parameters, and, optionally, a request 
context (Carre, column 3, lines 47-53). Carre also teaches that Object Request Brokers 
(ORBs) use a Remote Procedure Call (RPC) mechanism to route request messages to the 
target object (Carre, column 4, lines 1-6). In order to allow objects defined using 
different specifications, such as ASN.l and IDL, Carre teaches that the objects and 
addresses are converted between the two standards. However, Carre does not mention 
anything regarding a client generating a request for type information for an attribute or 
event. The clients in Carre's system do not request type information, but instead request 
a specific service from a particular server object and Carre's system automatically makes 
any conversions between different object specification languages necessarily to allow the 
client and server object to communicate. Thus, there is no need in Carre's system for a 
client to generate a request for type information for an attribute or event. In fact, the 
purpose of Carre's teachings appears to be to perform the address type conversion for the 
client so that the client does not have to modify it's own interface in order to 
communicate with an object employing a different addressing mode. See, e.g., col. 1, line 
43 - col. 2, line 6. Therefore, Carre actually teaches away from a client generating a 
request for type information for an attribute or event. 
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In the Response to Arguments, the Examiner repeats the assertion that Carre 
discloses a client generating a request for type information for an attribute or event, again 
citing the abstract, fig. 2a, 2b, column 3, lines 18-55, and column 5, lines 4 - 65 of 
Carre and referring to Carre's teachings regarding sending a receiving request and 
outcome messages. However, as noted above, Carre's requests are not requests for type 
information for an attribute or event. Instead, Carre's client requests a specific service 
from a particular server. 

Carre also fails to disclose sending the request for type information to an 
object request broker. The Examiner cites the Object Request Broker of FIG. 3a of 
Carre, referring to Carre's Object Request Broker. However, FIG. 3a illustrates a CMISE 
gateway to aid communication between objects by converting ASN types to a 
corresponding IDL types. FIG. 3a does not illustrate a client sending a request for type 
information to an object request broker. As noted above, clients of Carre's system send 
specific request messages to Object Request Brokers that include an operation, a target 
object, one or more parameters, and, optionally, a request context. Neither clients nor 
any other entities in Carre's send requests for type information to object request brokers. 

In the Response to Arguments, the Examiner again cites fig. 3a of Carre, but also 
cites column 5, lines 39-65 and column 6, lines 1 - 35. At column 5, lines 39- 65, Carre 
describes that the interface unit GDMO/IDL "translates the OSI objects OM and OA of 
the components from GDMO to IDL". Carre teaches that an "object so specified can be 
accessed by classic CORBA messages." This section of Carre has no relevance to a 
client sending a request for type information to an object request broker. 

The Examiner's other citation (column 6, lines 1-35) describes the steps 
involved in the address-type conversion used in Carre's system. Specifically, Carre 
describes how the ASN type of an OSI address value is converted to a correspondent IDL 
type that is structured to contain and transport both the CMIS/OSI full distinguished 
name and the CORBA object reference. However, as noted above, the mere fact that 
Carre's system includes converting address types as part of communication between 
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CORBA entities and OSI entities does not disclose or anticipate the specific limitation of 
sending a request for type information to an object request broker. 

Carre further fails to disclose a metadata gateway receiving the request for 
type information from the object request broker. The Examiner cites the CMISE 
Gateway of FIG. 3a and column 5, lines 39-65. However, the cited passage does not 
mention anything about a metadata gateway receiving a request for type information from 
an object request broker. FIG. 3a also fails to show anything about a metadata gateway 
receiving a request for type information. Carre teaches that by converting objects from 
the ASN.l specification to the IDL specification CMISE operations can be performed on 
CORBA objects, and vice versa (column 5, lines 24-39 and lines 60-65) but fails to teach 
anything about a metadata gateway receiving a request for type information from an 
object request broker. Nowhere does Carre describe that his CMISE gateway, cited by 
the Examiner, receives a request for type information from an object request broker. 
Applicants note that the Examiner has failed to respond to this argument in the Response 
to Arguments. 

Carre additionally does not disclose reading the type information from a 
metadata repository, wherein the type information is stored in a database format in 
the metadata repository. The Examiner cites CMISE/IDL FIG. 3. However, the cited 
CMISE/IDL is not a metadata repository from which type information is read. In the 
Response to Arguments, the Examiner refers to "using CMISE/IDL fig. 3 as a metadata 
repository to manage/store the OSI objects translated from type conversion" and also 
cites column 6, lines 1-35. Column 6, lines 1 - 35 of Carre, cited by the Examiner, 
describes the conversion of ASN types to a correspondent IDL type. However, Carre 
teaches that the CMISE/IDL is an "interface unit" that contains the "CMISE object and 
the services assigned to this object". Carre also teaches that the CMISE object is 
specified by an EDL interface and acts, and thus appears, like a CORBA object (Carre, 
column 5, lines 21-39). Thus, the CMISE/IDL cited by the Examiner is a communication 
interface that allows non-CORBA objects to be interacted with via standard CORBA 
interfaces. The CMISE/EDL interface unit is clearly not a metadata repository. 
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Moreover, Carre's gateway cannot be considered the metadata repository of Applicants' 
claim because specifically recites that type information is stored in a database format in 
the metadata repository. Carre's gateway does not store type information in a database 
format. 

Carre also fails to disclose the client receiving the translated type 
information for the attribute or event through the object request broker. The 

Examiner cites column 6, lines 10-35 of Carre. However, this portion of Carre does not 
describe a client receiving the translated type information for the attribute or event 
through the object request broker. Instead, as noted above, the cited passage is part of a 
description of converting objects from ASN to IDL and vice versa as well as caching of 
converting object instances. As described above, converting CMISE and CORBA 
objects is not the same as client generating a request to type information, and receiving 
the translated type information for the attribute or event through an object request broker. 
The Examiner's cited passage makes no mention of any client receiving translated type 
information for an attribute or event through an object request broker. 

Anticipation requires the presence in a single prior art reference disclosure of each 
and every limitation of the claimed invention, arranged as in the claim . M.P.E.P 2131; 
Lindemann Maschinenfabrik GmbH v. American Hoist & Derrick Co., 221 USPQ 481, 
485 (Fed. Cir. 1984). The identical invention must be shown in as complete detail as is 
contained in the claims. Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. 
Cir. 1989). As discussed above, Carre fails to disclose a client generating a request for 
type information for an attribute or event, a metadata gateway receiving the request for 
type information from an object request broker, reading the type information from a 
metadata repository, and the client receiving translated type information for the attribute 
or event through an object request broker. Therefore, for numerous reasons, Carre clearly 
cannot be said to anticipate claim 1 . 

The Examiner also asserts in the Response to Arguments, "Applicants clearly 
have still failed to identify specific claim limitations that would define clearly patentable 
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distinction over prior art." However, as discussed above, Carre fails to disclose the 
specific claim limitations of a client generating a request for type information for an 
attribute or event, sending the request for type information to an object request broker, a 
metadata gateway receiving the request for type information from the object request 
broker, reading the type information from a metadata repository, and the client receiving 
the translated type information for the attribute or event through the object request 
broker. Thus, the Examiner statement regarding Applicants not identifying specific claim 
limitations is clearly incorrect. 

For at least the reasons given above, the rejection of claim 1 is not supported by 
the cited art and removal thereof is respectfully requested. Similar remarks as those 
above regarding claim 1 also apply to claim 22. 

Regarding claim 2, Carre does not disclose translating the type information from 
the database format to an abstract syntax notation and translating the type information 
from the abstract syntax notation to the interface definition language. The Examiner cites 
column 1, lines 34-55 and column 5, line 60 - column 6, line 21, specifically referring to 
Carre's teachings regarding using semantic conversions. However, the cited passages, as 
well as the remainder of Carre, only describe converting address values from abstract 
syntax notation to interface definition language. For example, Carre teaches that an OSI 
address value is converted to a correspondent IDL type (Carre, column 6, lines 1-2). 
Please note that Carre teaches that OSI objects are specified in ASN (Carre, column 1, 
lines 40-42). Thus, the Examiner's cited passages describe converting between ASN and 
IDL (and the reverse), but fail to mention anything about translating from a database 
format to an abstract syntax notation. Applicants note that the Examiner has failed to 
provide any rebuttal to the above argument 

For at least the reasons above, the rejection of claim 2 is not supported by the 
cited art and removal thereof is respectfully requested. Similar remarks apply to claim 
23, as well. 
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Regarding claim 10, Carre fails to disclose a client generating a request to 
encode type information for an object, attribute, or event. The Examiner cites the 
Abstract, FIG. 2A and 2B as well as column 3, lines 18-55 and column 5, lines 4-38. The 
Examiner also specifically refers to Agent 1 of FIG. 3a, equating Agent 1 to the client of 
claim 10. However, Carre does not, either at the Examiner's cited passages or elsewhere, 
describe Agent 1 or any other client, generating a request to encode type information for 
an object, attribute, or event. As noted above regarding the rejection of claim 1, Carre is 
concerned with providing interface and address type conversions to allow objects 
specified according to different specification languages, such as ASN and IDL, to 
communicate and interact with each other by providing interfaces that allow non CORBA 
objects to appear as CORBA objects to the outside world. Clients in Carre's system do 
not generate requests to encode type information for objects, attributes or events. Instead, 
client objects in Carre's system invoke, via a standard CORBA interface, services 
provide by server objects. (Carre, column 1, lines 9-19; column 1, line 59-column 2, line 
46; column 5, lines 49-59). Nowhere does Carre mention a client generating a request to 
encode type information for an object attribute or event. 

In the Response to Arguments, the Examiner again refers to Carre's teachings 
regarding type translation, citing column 3, lines 18-55 and column 5, lines 20 - 58. 
However, Carre's address conversion has nothing to with a client generating a request to 
encode type information for an object, attribute or event. Instead, Carre's address type 
conversion is performed as part of communicating with CMISE object that appear as 
CORBA objects. Nowhere does Carre mention a client generating a request to encode 
type information. Instead, Carre's interface unit converts object instances and object 
instance values into an IDL type to allow communication between CORBA objects and 
CMISE objects. 

Additionally, Carre does not disclose sending the request to an object request 
broker and a metadata gateway receiving the request to encode type information 
from the object request broker. The Examiner cites ORB and CMISE Gateway of FIG. 
3a. However, Carre does not describe the ORB of FIG. 3a as receiving a request to 
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encode type information from a client. Nor does Carre describe the CMISE Gateway as 
receiving the request from the ORB. Instead, Carre teaches object request brokers 
provide an infrastructure that enables objects to communicate in a distributed 
environment such that "it makes no difference to" the requesting objects in which 
computer system or in which form the target object is implemented (Carre, column 3, 
lines 56-63). Carre also teaches that a requesting object sends a request message to an 
object request broker and that the object request broker routes the request message to the 
target object (Carre, column 3, line 64-column 4, line 6). Thus, Carre teaches that object 
request brokers route request messages from a request object to the target object. Carre 
does not mention anything about object request brokers receiving requests to encode type 
information from a client or about a metadata gateway receiving such request from an 
object request broker. 

Carre further fails to disclose storing the type information in a metadata 
repository, where the type information is stored in a database format in the metadata 
repository. The Examiner cites CMISE/IDL of FIG. 3 and column 6, lines 10-35, 
specifically referring to Carre's conversion of address types from OSI types. However, 
the portions of Carre cited by the Examiner refer to the caching of structures, such as 
object instance values and object reference pairs for addresses already in an entity. 
Caching of object values and references is no the same as storing type information in a 
database format in a metadata repository. Additionally, as noted above regarding the 
rejection of claim 1, the CMISE/IDL interface unit cited by the Examiner is clearly a 
communication interface that allows non-CORBA objects to be interacted with via 
standard CORBA interfaces (Carre, column 5, lines 21-39). The CMISE/IDL interface 
unit is clearly not a metadata repository. Moreover, Carre does not describe or even 
mention anything regarding storing type information in the CMISE/IDL interface unit. 

As discussed above, Carre fails to disclose the specific limitations as arranged in 
claim 10. Therefore, Carre clear fails to anticipate claim 10. For at least the reasons 
presented above, the rejection of claim 10 is not supported by the cited art and removal 
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thereof is respectfully requested. Similar remarks as those above regarding claim 10 
apply to claim 27 as well. 

Regarding claim 11, Carre fails to disclose translating the type information from 
the interface definition language to an abstract syntax notation and translating the type 
information from the abstract syntax notation to the database format . The Examiner cites 
column 1, lines 34-55 and column 5, line 60 - column 6, line 21, specifically referring to 
Carre's use of semantic conversions. However, the cited passages, as well as the 
remainder of Carre, only describe converting address values from abstract syntax notation 
to interface definition language and from interface definition language to abstract syntax 
notation. For example, Carre teaches that an OSI address value is converted to a 
correspondent IDL type (Carre, column 6, lines 1-2). Please note that Carre teaches that 
OSI objects are specified in ASN (Carre, column 1, lines 40-42). Thus, the Examiner's 
cited passages describe converting between ASN and IDL (and the reverse), but fail to 
mention anything about translating from an abstract syntax notation to a database format. 
Applicants note that the Examiner has failed to provide any rebuttal to the above 
argument 

For at least the reasons above, the rejection of claim 11 is not supported by the 
cited art and removal thereof is respectfully requested. Similar remarks also apply to 
claim 28. 

Regarding claim 14, Carre fails to disclose a metadata repository comprising 
metadata concerning object classes for a plurality of managed objects, wherein the 
metadata comprises information expressed in a database format, and wherein the 
managed objects correspond to managed devices on a network. The Examiner cites 
CMISE/IDL of FIG. 3a as well as the abstract, FIGs 2A, 3 A, column 3, lines 18-55 and 
column 5, lines 4-38 of Carre. However, as noted above, regarding the rejections of 
claim 1 and 10, the CMISE/IDL interface unit cited by the Examiner is clearly a 
communication interface that allows non-CORBA objects to be interacted with via 
standard CORBA interfaces (Carre, column 5, lines 21-39). The CMISE/IDL interface 
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unit is clearly not a metadata repository. Moreover, Carre does not describe or even 
mention anything regarding storing metadata concerning object classes in the 
CMISE/IDL interface unit. Nowhere does Carre describe anything about storing 
metadata concerning object classes in a metadata repository. 

Carre also fails to disclose a metadata gateway coupled to the metadata repository 
and to an object request broker, where the metadata gateway is operable to send and 
receive metadata from the database, where the metadata gateway provides translation of 
the metadata to and from the database format and an interface definition language. The 
Examiner cites CMISE Gateway of FIG. 3a. However, Carre's CMISE Gateway 
provides address type conversion between two different object interface specifications, 
such as between IDL and C++, as illustrated in FIG. 3a. Carre's CMISE gateway is not 
coupled to a metadata repository. As noted above, the CMISE/IDL interface unit cited by 
the Examiner is clearly not a metadata repository (and neither is the CMISE/C++ 
interface unit) and thus the CMISE Gateway is not coupled to metadata repository. 
Nowhere does Carre describe his CMISE Gateway as being coupled to a metadata 
repository. Furthermore, Carre's CMISE Gateway is not operable to send and receive 
metadata. Instead, as shown above, the CMISE Gateway translates object interfaces as 
expressed via CORBA RPC request messages (Carre, column 3, line 54 - column 4, lines 
16; and column 5, line 60 - column 6, line 9). 

Additionally, Carre fails to disclose where the metadata gateway provides 
translation of the metadata to and from the database format and an interface definition 
language. As noted above, Carre's CMISE Gateway provides address type conversion 
between two different object interface specifications, such as between IDL and C++, not 
between a database format and IDL. As noted above regarding the rejection of claim 2, 
Carre does not mention anything regarding converting metadata to or from a database 
format. Applicants note that the Examiner has failed to provide any rebuttal to the 
above argument. 
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Thus, for at least the reasons presented above, the rejection of claim 14 is not 
supported by the cited art and removal thereof is respectfully requested. 

Regarding claim 17, Carre fails to disclose wherein the metadata gateway 
includes a library of data types expressed in an abstract syntax notation , a plurality of 
object types, wherein each object type includes one or more of the data types from the 
library of data types. The Examiner cites, FIG. 2 A, 3 A, column 4, lines 7-62 and column 
5, line 39 to column 6, line 35 of Carre. However, the Examiner has failed to cite any 
portion of Carre that describes a library of data types expressed in an abstract syntax 
notation. Additionally, Carre's CMISE Gateway, which the Examiner equates to the 
metadata gateway of Applicants' claims, does not include a library of data types. Carre 
makes no mention of his CMISE Gateway including a library of data types expressed in 
an abstract syntax notation. Instead, Carre describes his CMISE Gateway as providing 
address type conversion between two different object interface specifications, such as 
between IDL and C++. Merely providing address type conversion does not imply 
including a library of data types and a plurality of object type, each including one or more 
of the data types from the library. The Examiner's interpretation of Carre's CMISE 
Gateway is incorrect. 

Additionally, Carre also fails to disclose wherein the metadata gateway includes 
an interface to the plurality of object types , wherein the interface is operable to provide 
one or more clients with access to the metadata as expressed in the interface definition 
language. The Examiner has not cited any portion of Carre that describes the CMISE 
Gateway, which the Examiner equates to the metadata gateway of Applicants' claims, as 
including an interface to a plurality of object types, where the interface provides clients 
with access to the metadata. Carre's CMISE Gateway translates objects and object 
address types from ASN to IDL and from IDL to ASN. Nowhere does Carre describe 
that the CMISE Gateway includes an interface providing clients access to metadata. 
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In the Response to Arguments, the Examiner merely repeats the rejection of claim 
17, without providing any additional argument or explanation in rebuttal to 
Applicants' arguments. 

Thus, for at least the reasons above, the rejection of claim 17 is not supported by 
the cited art and removal thereof is respectfully requested. 

Section 103(a) Rejection : 

The Examiner rejected claims 6, 13, 15 and 16 under Carre in view of Kung et al. 
(U.S. Patent 6,775,267) (hereinafter "Kung"). Applicants respectfully traverse this 
rejection for at least the reasons presented above regarding their respective independent 
claims. 

Regarding both the § 102 and § 103 rejections, Applicants also assert that 
numerous ones of the dependent claims recite further distinctions over the cited art. 
However, since the rejection has been shown to be unsupported for the independent 
claims, a further discussion of the dependent claims is not necessary at this time. 

Request Pursuant to M.P.E.P. § 707.02 : 

In the previous response, filed February 2, 2006, Applicants noted that there have 
been four different rejections asserted in this application without any substantive 
amendment having ever been made to any of the independent claims. Applicants also 
noted that this application has been pending for well over five years. Pursuant to 
M.P.E.P. § 707.02, Applicants requested that a Supervisory Patent Examiner review this 
application "with a view to finally concluding its prosecution." According to M.P.E.P. § 
707.02, this application "should be carefully studied by the supervisory patent examiner 
and every effort should be made to terminate its prosecution." Applicants have not 
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received any response to, or acknowledgment of, the previous request. Applicants hereby 
repeat and maintain the request that a Supervisory Patent Examiner review this 
application. 

As noted in Applicants' remarks above, the application is clearly in condition for 
allowance. If there are any questions concerning the allowability of the present 
application, Applicants' undersigned attorney earnestly requests a telephone conference 
with the Supervisory Patent Examiner to expeditiously resolve any outstanding issues. 
Applicants also noted in the previous response that according to M.P.E.P. § 707.02, this 
application "is to be considered 'special' by the examiner." 
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CONCLUSION 

Applicants submit the application is in condition for allowance, and prompt notice 
to that effect is respectfully requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5181- 
46200/RCK. 

Also enclosed herewith are the following items: 
£3 Return Receipt Postcard 
I I Petition for Extension of Time 
Q Notice of Change of Address 
□ Other: 



Respectfully submitted, 




Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone:(512) 853-8850 

Date: June 15,2006 
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